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Infrastructure ENUM Requirements 
Status of This Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Abstract 


This document provides requirements for "infrastructure" or "carrier" 
ENUM (E.164 Number Mapping), defined as the use of RFC 3761 
technology to facilitate interconnection of networks for E.164 number 
addressed services, in particular but not restricted to VoIP (Voice 
over IP.) 
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1%: Infrastructure ENUM 
1.1. Definition 


Infrastructure ENUM is defined as the use of the technology in RFC 
3761 [1] by the carrier-of-record (as defined below) for a specific 
E.164 number [2] to publish the mapping of the E.164 number into a 
URI [3] that identifies a specific point of interconnection to that 
service provider’s network. It is separate from any URIs that the 
end user, who registers their E.164 number, may wish to associate 
with that E.164 number. 


Lind & Pfautz Informational [Page 1] 


RFC 5067 Infrastructure ENUM Requirements November 2007 


"Infrastructure ENUM" is distinguished from "End User ENUM", defined 
in RFC3761 [1], in which the entity or person having the right to use 
a number has the sole discretion about the content of the associated 
domain and thus the zone content. From a domain registration 
perspective, the end user number assignee is thus the registrant. 
within the infrastructure ENUM namespace, we use the term "carrier- 
of-record" for the entity having discretion over the domain and zone 
content and acting as the registrant. The "carrier-of-record" is: 


o The Service Provider to which the E.164 number was allocated for 
end user assignment, whether by the National Regulatory Authority 
(NRA) or the International Telecommunication Union (ITU), for 
instance, a code under "International Networks" (+882) or "Universal 
Personal Telecommunications (UPT)" (+878) or, 


o if the number is ported, the service provider to which the number 
was ported, or 


o where numbers are assigned directly to end users, the service 
provider that the end user number assignee has chosen to provide a 
Public Switched Telephone Network/Public Land Mobile Network (PSTN/ 
PLMN) point-of-interconnect for the number. 


It is understood that the definition of carrier-of-record within a 
given jurisdiction is subject to modification by national 
authorities. 


1.2. Background 


Voice service providers use E.164 numbers currently as their main 
naming and routing vehicle. Infrastructure ENUM in el64.arpa or 
another publicly available tree allows service providers to link 
Internet-based resources such as URIs to E.164 numbers. This allows 
service providers, in addition to interconnecting via the PSTN/PLMN 
(or exclusively), to peer via IP-based protocols. Service providers 
may announce all E.164 numbers or number ranges they host, regardless 
of whether the final end user device is on the Internet, on IP-based 
open or closed Next Generation Networks (NGNs), or on the PSTN or 
PLMN, provided that an access point of some type to the destination 
service provider’s network is available on the Internet. There is 
also no guarantee that the originating service provider querying 
infrastructure ENUM is able to access the ingress network element of 
the destination provider’s network. Additional peering and 
accounting agreements requiring authentication may be necessary. The 
access provided may also be to a shared network of a group of 
providers, resolving the final destination network within the shared 
network. 
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2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in BCP 14, RFC2119 [4]. 


3. Requirements for Infrastructure ENUM 


1. Infrastructure ENUM SHALL provide a means for a provider to 
populate DNS resource records (RRs) for the E.164 numbering 
resources for which it is the carrier-of-record in a single 
common publicly accessible namespace. The single common 
namespace ultimately designated may or may not be the same as 
that designated for End User ENUM (el64.arpa.) The Fully- 
Qualified Domain Name (FODN) in the resulting resource records 
will not necessarily belong to or identify the carrier-of-record. 


2. Queries of infrastructure ENUM fully qualified domain names MUST 
return a result, even if the result is Refused (RCODE = 5). 
Queries must not be rejected without response, e.g., based on 
access control lists. 


3. Infrastructure ENUM SHALL support RRs providing a URI that can 
identify a point of interconnection for delivery to the carrier- 
of-record of communications addressed to the E.164 number. 


4. Infrastructure ENUM SHOULD be able to support an Internet 
Registry Information Service (IRIS) [5] capability that allows 
qualified parties to obtain information regarding the E.164 
numbering resources and the corresponding carrier-of-record. 
Determination of what information, if any, shall be available 
which parties for geographic numbers is a national matter. 


5. Implementation of infrastructure ENUM MUST NOT restrict the 
ability of an end user, in a competitive environment, to choose a 
Registrar and/or name server provider for End User ENUM 
registrations. 


6. The domain name chosen for infrastructure ENUM and any parent 
domains MUST be hosted on name servers that have performance 
characteristics and supporting infrastructure that is comparable 
to those deployed for the Internet root name servers. Those name 
servers for infrastructure ENUM should be configured and operated 
according to the guidelines described in [6]. 


7. Infrastructure ENUM MUST meet all reasonable privacy concerns 


about visibility of information over which an end user has no 
control. It should, for example, support mechanisms to prevent 
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discovery of unlisted numbers by comparison of ENUM registrations 
against directory listings, or inadvertent disclosure of user 
identity. 


8. Proposed implementations of infrastructure ENUM SHOULD: 


A. Minimize changes required to existing requirements that are 
part of RFC 3761. 


B. Work with open as well as closed numbering plans. 


C. Not require additional functionality of resolvers at large 
though they may require additional functionality in service 
provider resolvers that would make use of infrastructure 
ENUM. 


D. Minimize the number of lookups required to obtain as many 
NAPTR (Naming Authority Pointer) records (end user and 
infrastructure) as possible. 


E. Minimize knowledge of the numbering plan required of 
resolvers making use of Infrastructure ENUM. 


F. Maximize synergies with End User ENUM. 


G. Support interworking with private ENUM trees. (In this 
context, a private ENUM tree is one that is not under 
el64.arpa or whatever namespace is chosen for infrastructure 
ENUM but uses instead a privately held domain.) 


4. Security Considerations 
Existing security considerations for ENUM (detailed in [1]) still 
apply. Since infrastructure ENUM involves carriers where RFC 3761 


mainly considered indviduals, implementations meeting these 
requirements SHOULD reconsider the RFC 3761 security model given this 
difference in actors concerned. Note that some registration 
validation issues concerning End User ENUM may not apply to 
infrastructure ENUM. Where the Tier 1 registry is able to identify 
the provider serving a number, e.g., based on industry data for 
number block assignments and number portability, registration might 
be more easily automated and a separate registrar not required. 


Some parties have expressed concern that an infrastructure ENUM could 
compromise end user privacy by making it possible for others to 
identify unlisted or unpublished numbers based on their registration 
in ENUM. This can be avoided if providers register all of the their 
allocated (as opposed to assigned) numbers. Unassigned numbers 
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should be provisioned to route to the provider’s network in the same 
fashion as assigned numbers and only then provide an indication that 
they are unassigned. In that way, provider registration of a number 
in ENUM provides no more information about the status of a number 
than could be obtained by dialing it. 


Implementers should take care to avoid inadvertent disclosure of user 
identities, for example, in the URIs returned in response to 
infrastructure ENUM queries. 


5. IANA Considerations 


This document includes no actions to be taken by IANA. The 
architecture ultimately chosen to meet the requirements may require 
IANA actions. 
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